Communications systems evolve more and more towards an Internet Protocol (IP)-based network. They typically consist of many interconnected networks, in which speech and data is transmitted from one terminal to another terminal in pieces, so-called packets. IP packets are routed to the destination by routers in a connection-less manner. Therefore, packets comprise IP header and payload information, whereby the header comprises among other things source and destination IP address.
For scalability reasons, an IP network uses a hierarchical addressing scheme. Hence, an IP address does not only identify the corresponding terminal, but additionally contains location information about this terminal. With additional information provided by routing protocols, routers in the network are able to identify the next router towards a specific destination.
When a terminal powers on, it configures an IP address that is based on the IP address prefix of the access network. If a terminal is mobile, a so-called mobile node (MN), and moves between subnets with different IP prefix addresses, it must change its IP address to a topological correct address due to the hierarchical addressing scheme. However, since connections on higher-layers such as TCP connections are defined with the IP addresses (and ports) of the communicating nodes, the connection to the active IP sessions breaks if one of the nodes changes its IP address, e.g. cue to movement.
Mobile IPv6—also denoted MIPv6—(see D. Johnson, C. Perkins, J. Arkko, “Mobility Support in IPv6”, IETF RFC 3775, June 2004, available at http//www.ietf.org and incorporated herein by reference) is an IP-based mobility protocol that enables mobile nodes to move between subnets in a manner transparent for higher layers and applications, i.e. without breaking higher-layer connections. That is, the mobile nodes remain reachable while moving around in the IPv6 internet network. The main principle of MIPv6 is that a mobile node is always identified by its Home Address (HoA), regardless of its topological location in the internet, while a Care-of Address (CoA) of the mobile node provides information about the current topological location of the mobile node.
In more detail, a mobile node has two IP addresses configured: a Care-of Address and a Home Address. The mobile node's higher layers use the Home Address for communication with the communication partner (destination terminal), from now on called Correspondent Node (CN). This address does not change and serves the purpose of identification of the mobile node. Topologically, it belongs to the Home Network (HN) of the mobile node. In contrast, the Care-of Address changes on every movement resulting in a subnet change and is used as the locator for the routing infrastructure. Topologically, it belongs to the network the mobile node is currently visiting. One out of a set of Home Agents (HA) located on the home link maintains a mapping of the mobile node's Care-of Address to mobile node's Home Address and redirects incoming traffic for the mobile node to its current location. Reasons for deploying a set of home agents instead of a single home agent may be redundancy and toad balancing.
Mobile IPv6 currently defines two modes of operation: bi-directional tunneling (FIG. 1) and route optimization (FIG. 2). Using bidirectional tunneling, data packets sent by the correspondent node 101 and addressed to the home address of the mobile node 102 are intercepted by the home agent 111 in the home network 110 and tunneled to the Care-of Address of the mobile node 102, which is anchored at the foreign network 120. Data packets sent by the mobile node 102 are reverse tunneled to the home agent 111, which decapsulates the packets and sends them to the correspondent node 101. Reverse tunneling means that packets are transmitted by the mobile node via an additional reverse tunnel (to complement the “normal” one) that starts at the mobile node and terminates at the home agent.
For this operation in MIPv6, only the Home Agent 111 is informed about the Care-of Address of the mobile node 102. Therefore, the mobile node sends Binding Update (BU) messages to the Home Agent. These messages are sent over an IPsec security association, and thus are authenticated and integrity protected. A drawback is that if the mobile node is far away from the home network and the correspondent node is close to the mobile node, the communication path is unnecessarily long, resulting in inefficient routing and high packet delays.
The route optimization mode (see FIG. 2) can prevent the inefficiency of the bi-directional tunneling mode by utilizing the direct path between correspondent node and mobile node. When using route optimization, the mobile node sends binding update messages to the correspondent node, which then is able to directly send data packets to the mobile node (a type 2 routing header is used to send the packets destined to the mobile node's home address on the direct path to the mobile node's care-of address). Of course, the correspondent node has to implement Mobile IPv6 route optimization support.
More specifically, in order to perform route optimization, the mobile nodes and correspondent nodes exchange signaling messages, being part of the Mobility Header protocol, which is an extension header used by mobile nodes, correspondent nodes and home agents in all messaging related to the creation and management of bindings. With respect to route optimization, 4 message types are specified in the mobility header protocol.
FIG. 3 depicts the signaling flow performed for RO in MIPv6. The protection of Binding Updates sent to correspondent nodes does not require the configuration of security associations or the existence of an authentication infrastructure between the mobile nodes and correspondent nodes. Instead, a method called the Return Routability Procedure is used to assure that the right mobile node is sending the message.
The Return Routability Procedure enables the correspondent node to obtain some reasonable assurance that the mobile node is in fact addressable at its claimed Care-of Address as well as at its home address. Only with this assurance is the correspondent node able to accept Binding Updates from the mobile node which would then instruct the correspondent node to direct that mobile node's data traffic to its claimed Care-of Address.
This is done by testing whether packets addressed to the two claimed addresses are routed to the mobile node. The mobile node can pass the test only if it is able to supply proof that it received certain data (the “keygen tokens”) which the correspondent node sends to those addresses. These data are combined by the mobile node into a binding management key. The integrity and authenticity of the Binding Updates messages to correspondent nodes is protected by using the binding management key.
The MN sends two messages to the CN, each however over a different route. One message—Home Test Init (HoTi) message—is sent to the HA over the MIP IP-in-IP tunnel, which in turn forwards the message to the CN. A mobile node sends a Home Test Init message to the correspondent node (via the home agent) to acquire the home keygen token. As apparent from FIG. 3 the message comprises the home init cookie that the CN must return later, and conveys the home address of the MN to the CN. The other message—Care-of Test Init (CoTi)—is sent directly to the CN in order to obtain the care-of keygen token. The CoTi message informs the CN about the current Care-of Address of the MN, and comprises the care-of-init cookie.
After receiving the HoTi and CoTi messages, the CN sends two messages back to the MN again over different routes. The Home Test (HoT) message is sent to the MN's HoA, i.e. to the HA in response to the HoTi message, The HA then forwards the message to the MN over the MIPv6 tunnel. Accordingly, the Care-of Test (CoT) message is sent directly to the MN. Both messages HoT and CoT respectively contain “home keygen token” and “care-of keygen token”, respectively along with the home init cookie and the care-of-init cookie received from the previous HoTi and CoTi messages. Both tokens are based on CN's currently active secret key, nonces, and home or care-of address (respectively).
After the HoT and CoT messages arrive at the MN, the MN uses the keygen tokens and generates a binding management key from the tokens received with the HoT and CoT messages. After the mobile node has created the binding management key, it can supply a verifiable Binding Update to the correspondent node. After receiving the Binding Update message, the CN can update its binding cache with the binding of MN's HoA and CoA.
Thus, MIPv6 allows to optimize the route between the CN and the MN by allowing a mapping in the CN of the HoA and CoA of the MN, so that the both nodes can communicate directly.
One alternative to the MIPv6 approach for keeping the existing active IP sessions alive is to configure the serving access routers (AR) to advertise the same set of IP prefixes, so that the MN can keep using the IP addresses that have been configured at the old ARs. This approach is called network-based mobility management. One network-based mobility mechanism under standardization in IETF is “Network-based Localized Mobility Management” (NetLMM). One main characteristic of network-based mobility is that the MN is not involved in the mobility process, and thus, no signaling over the air interface is needed. The MIPv6 approach described in the previous paragraphs is known as host-based mobility because the MN is included in the mobility process, as the MN announces its CoA to the HA or CN, by sending Binding Update messages.
NetLMM defines two protocol entities, a Mobile Access Gateway (MAC) and a Local Mobility Anchor (LMA), and a set of messages between them. MAG is a router embedded in a device that terminates a specific link layer technology to which mobile nodes attach themselves. LMA is a router that terminates connections to multiple MAGs and handles mobility requests for mobile nodes moving within a NetLMM system. The data packets to/from the MNs are tunneled between the LMA and MAGs. When a MN moves from an old MAG to a new MAG, the LMA is notified about the location change and starts tunneling the MN's data packets to the new location (new MAG).
If the MN moves between two distinct NetLMM domains, the usual mobility solution would be MIPv6. Additionally, there are approaches to solve inter-NetLMM mobility (or mobility between local mobility anchors, i.e. inter-LMA mobility) by network-based mechanisms. One such approach is introduced by 3GPP for roaming scenarios, i.e. mobility between different operators. When a MN moves to a visited operator's network, the MN's data traffic is forwarded to the home operator's network, then the home operator routes the traffic to the visited operators network. One reason to have network-based mobility may be that the home operator wants to control the mobility, policy and charging of the MN's data traffic.
FIG. 4 shows an overview of a network architecture and a communication data route between the CN and MN, while the MN moves from operator 1 to operator 2. At the beginning the MN 102 registers in Access Network 1 110 (NetLMM area 110 is also the home network for the MN), and starts the communication with ON 101 via the serving LMA1 111. When the MN moves to AN2 120, it first registers and authenticates itself with the network. During the registration process, AN2 contacts AN1 to verify the identity of the MN. During the information exchange between AN1 and AN2, AN2 learns the IP prefix (and/or IP address) of the MN 102 and is thus enabled to hide the network layer mobility to the MN 102, by advertising the same IP prefix to the MN 102 via MAG3 122. That is, MN 102 still thinks that it is on the same IP subnet. For this purpose, the location of the MN 102 needs to be registered in LMA1 and LMA2. Further, tunnels between LMA1 and LMA2 and between LMA2 and MAG3 have to be set up in order to exchange the MN's traffic,
The traffic from outside continues to arrive at LMA1 after the handover, because the MN continues to use the original IP address in the visited network which is anchored at LMA1. (The terms within the boxes correspond to the NetLMM terminology, and the terms in the parentheses correspond to 3GPP SAE terminology.)
As apparent from FIG. 4 the data route between the 101 CN and the MN 102, after the MN 102 moves to another access network, is unnecessarily long, especially in cases in which the CN 101 and the MN 102 are located topologically near. This results in inefficient routing and in high data packet delays, which is e.g. critical for real-time services.